REMARKS 

In the Final Office Action mailed December 12, 2006, the Examiner rejected 
claims 8-1 1 , 22, and 26-29 under 35 U.S.C. § 1 03(a) as being unpatentable over Mack 
(U.S. Patent No. 6,192,044) in view of Myrick etal. (U.S. Patent No. 5,978,852), and 
further in view of Lorenz (U.S. Patent No. 5,892,922). Claims 12-21, 23, 24 and 30-39 
are currently withdrawn from consideration as being drawn to a non-elected invention. 

Applicants respectfully traverse the rejections of claims 8-11, 22, and 26-29 for at 
least the following reasons. 

The Interview Conducted February 9, 2007 

Applicants wish to thank Examiners Beatriz Prieto and Benjamin A. Ailes for the 
courtesies extended during the interview held February 9, 2007, with Applicants' 
representative. During the interview, Applicants' representative explained that the 
rejections set forth in Final Office Action lack support in Mack , Myrick et al. and Lorenz , 
whether taken alone or in combination. As requested by the Examiners, Applicants 
submit the following remarks to reiterate the arguments presented in the interview. 

Claims 8, 22 and 26 

With respect to claims 8, 22 and 26, the Examiner asserts that 

Mack teaches the use of a lookup service in a network 
system wherein a user queries the lookup service to acquire 
access to further locations within the network, the lookup 
service including the ability to send the requestor necessary 
information in order to complete the connection, deemed 
functionally equivalent to applicants claimed stub or 
serialized object 

Office Action (December 12, 2006), p. 2, I. 24 through p. 3, I. 4 (citing Mack , col. 4, II. 
30-35; col. 6, II. 33-45 and FIGS. 7-8). 



The Examiner goes on to assert that "[t]he claim limitation 'stub 1 as read broadly 
is software or equivalent thereof that aids a user to access a service. What is cited in 
Mack (col.,. 6, II. 37-45) is merely an example of a lookup service (194) 'stub' and 
therefore is within the scope of the claim having the same claimed functionality." Office 
Action (December 12, 2006), p. 5, II. 9-13. 

However, Applicants respectfully disagree with the Examiner's assertion that 
Mack teaches either a stub or a serialized object. As explained in the responses filed 
October 7, 2003 and February 9, 2006, Applicants have provided a section of the 
specification entitled, "The Lookup Service Definition." In that section, Applicants state 
that "a 'stub' is code and data that facilitates access to a remote function, and a 
'serialized object' is an object placed in serialized form." Specification, p. 13, II. 8-9. The 
term "stub" in Applicants' claims must be interpreted in light of the definition provided in 
Applicants' specification. M.P.E.P. § 2111.01 (8th Ed., Rev. 5, Aug. 2006). 

Mack describes a system 10 for establishing a network telephone connection 

between a caller PC 14 and a callee PC 18. With reference to FIG. 7, the portion of 

Mack cited by the Examiner as teaching a "stub" (i.e., Mack , col. 6, II. 37-45) reads, in 

its entirety, as follows: 

FIG. 7 is a flowchart illustrating the processing steps for a 
lookup service, in accordance with one embodiment of the 
present invention. In step 700, a caller 14 sends a request 
to a lookup server 194. This request includes a user 
identifier that is unique to the callee 18. For example, a user 
identifier can include a person's name, postal address, 
electronic mail address, social security number, and other 
commonly used identifiers. In step 702, the lookup service 
194 queries an association table with the user identifier for a 
user network access provider machine address and also the 
user telephone number. In step 704, the look-up service 194 
sends the caller 14 this user address and telephone number. 



Mack , col. 6, II. 37-45 (emphasis added). 

Contrary to the Examiner's assertions, the "information" the lookup server 194 
sends to the caller 14 is not "code and data that facilitates access to a remote function." 
Rather, the information is described only as an address and telephone number. Thus, 
the information is not a "stub" as that term is used in the rejected claims. Further, the 
"information" the lookup server 194 sends to the caller 14 is not "software or equivalent 
thereof that aids a user to access a service." Thus, the information does not even meet 
the Examiner's own definition of a "stub." Office Action (December 12, 2006), p. 5, II. 9- 
13. Consequently, the "information" the lookup server 194 sends to the caller 14 is 
neither a stub, nor a serialized object as alleged by the Examiner. 

Further, neither Myrick et al. nor Lorenz are relied upon to teach the claimed stub 
or serialized object, and neither of these references cure the above-noted deficiency of 
Mack . Rather, Myrick et al. discloses an "address look-up table" which contains the 
addresses of workstations residing on a local area network (LAN). Myrick et al. , col. 1, 
II. 48-60. And Lorenz discloses a "memory look-up table 30" that contains pointers to 
addresses in a memory. Lorenz , col. 4, II. 9-13. 

Thus, contrary to the Examiner's assertions, Mack , Myrick et al. and Lorenz 
(whether viewed singly or in any combination) do not teach or suggest the claimed 
service item containing one of a stub or serialized object for use in accessing at least 
one of the services. Even if the "address and telephone number" of Mack is 
"functionally equivalent" to a stub or serialized object, as alleged by the Examiner, the 
Examiner has shown no suggestion or motivation to modify the system of Mack to 
produce the claimed invention. 
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In addition, the Examiner admits that " Mack does not . . . explain how the lookup 
service is updated or maintained." Office Action (December 12, 2006), p. 3, II. 5-6. And 
the Examiner further admits that " Mvrick does not . . . teach the step of 'updating the 
lookup service such that the associated services unaffected by the update continue to 
be available for use while the update occurs."' ]d., p. 3, II. 14-16. In an attempt to cure 
this deficiency, the Examiner cites Lorenz as teaching "concurrent database 
accessing/updating . . . wherein a database memory look-up table can be updated and 
maintained and a lookup service can run simultaneously," and asserts that it would have 
been obvious to combine the features taught and described by Myrick and Lorenz with 
the teachings of Mack. \±, at p. 3, II. 17-20. 

However, Applicants respectfully disagree with the Examiner's characterization of 
Lorenz . Contrary to the Examiner's assertions, Lorenz does not teach "concurrent 
database accessing/updating." Rather, in the Lorenz system, "[a] switch processor 52 
initializes, updates and maintains the memory look-up table 30" (which the Examiner 
equates with the claimed lookup service). Lorenz . col. 4, II. 23-25. Access to the 
memory lookup table 30 is controlled by a "req_arb state machine" represented in FIG. 
5. jd., col. 4, II. 46-48. "The req-arb state machine has the states idle, look-up also 
referred to as gbi, and processor also referred to as proc [(indicating that the switch 
processor 52 is updating the memory lookup table 30)]." \±, col. 2, II. 53-55. "[0]nly 
one of the states is active at any one time." \±, col. 6, II. 9-10. "When the req_arb state 
machine [51] is in the gbi state [(i.e., the look-up state, indicating that the memory look- 
up table 30 is being used)] .... [a]ny access from the [switch] processor [52], read or 
write, is stalled until the look-up is completed." ]d., col. 4, II. 63-65. 



Thus, contrary to the Examiner's assertions, the req_arb state machine 
effectively prevents use of the data in the memory lookup table 30 while a write update 
occurs. Consequently, even if "[o]ne of ordinary skill in the art . . . would have found it 
obvious to combine the features taught and described by Myrick and Lorenz with the 
teachings of Mack" (which Applicants dispute), the resulting system would not allow 
"updating the lookup service such that the associated services unaffected by the update 
continue to be available for use while the update occurs," as alleged by the Examiner. 

For at least these reasons, Applicants submit that the Examiner's rejections of 
claims 8, 22 and 26 under 35 U.S.C. § 103(a) lack support in Mack . Myrick et al. and 
Lorenz , taken alone or in combination. Accordingly, Applicants respectfully request that 
the rejections of claims 8, 22 and 26 under 35 U.S.C. § 103(a) be withdrawn and the 
claims allowed. 

Claims 9-11 and 27-29 

Claims 9-1 1 and 27-29 depend from one of claims 8 and 26. As explained, the 
Examiner's rejection of claims 8 and 26 lacks support in Mack , Myrick et al. and Lorenz . 
whether taken alone or in any combination. Therefore, the rejections of claims 9-1 1 and 
27-29 likewise lack support in Mack . Myrick et al. and Lorenz for at least the same 
reasons given above with respect to independent claims 8 and 26. Accordingly, 
Applicants respectfully request that the rejections of claims 9-1 1 and 27-29 under 35 
U.S.C. 103(a) be withdrawn and the claims allowed. 



Conclusions 

In view of the foregoing amendments and remarks, Applicants respectfully 
request reconsideration and reexamination of this application and the timely allowance 
of the pending claims. 

Please grant any extensions of time required to enter this response and charge 
any additional required fees to our deposit account 06-0916. 



Respectfully submitted, 



FINNEGAN, HENDERSON, FARABOW, 
GARRETT & DUNNER, LLP. 



Dated: February 12, 2007 
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